4. Documenting Requirements

Return to TOC

Documentation

• use cases:
  • have been around a while
  • descriptions of how the system acts based on user input
  • document functional requriements
  • Use Case Model: set of use cases
  • actor: anything that does something
    • primary actor: has user goals fulfilled through use of the system under discussion
    • supporting actor: provides a service to the system under discussion
    • offstage actor: has an interest in the behavior
  • elementary business process (EBP)
    • a task performed by one person in one place at one time that adds measurable business value and leaves the data in a consistent state
    • focus on use cases involving EBPs
  • focus on intent; not implementation (e.g. don't focus on UI)
• user stories:
  • more recent, in agile
  • simple, informal; provided in small increments
  • Title, As a [role], I want [feature] so that [benefit]

Least wrong estimation technique:
Work together a few weeks, get some stuff done, review the work done, pick an "average"/"medium" piece of work

Use Case Modeling

Filter out domain objects that are attributes (number or string), implementation/UI, plural

System Sequence Diagrams (SSDs)

• picture showing events that external actors generate, their order, inter-system events for particular use case

SSDs use a dotted line for return values for solid lines

GUI Prototype -> Use Case Model, Sequence Diagram (Dynamic) -> Domain Model, Class Diagram (Static) -> Code
OOA (OO Analysis, figure out WHAT) > OOD (OO Design, figure out how) > OOP (OO Programming, implementation)